【セッションレポート】Developers.IO 2015 Treasure DataのAWS活用法 #cmdevio2015B

はじめに

Developers.IO 2015にスタッフとして参加しました。
trackBで行われた、「Treasure DataのAWS活用法」についてのレポートです。

セッション概要

Treasure Dataは、データの収集・蓄積・分析をクラウド上で提供するデータマネージメントサービスです。

現在はAWS/IDCF上でサービスを展開しているようです。

今回のセッションはTreasure DataのサービスがAWS上でどのようにスケーラブルなサービスを構築しているかお話をしていただきました。

スピーカーはトレジャーデータ株式会社の中川 真宏さんです。

内容について

Treasure Data System Overview

Treasure Data Systemの概要です。

・Job Queue
RDB上に作られている

・worker
データのインポートやクエリを担当する
HadoopやPrestoにクエリを投げる

Plazmaについて

Plazmaとはデータを保管/処理する仕組みです。

 

・Data import
50万レコードが毎秒インポートされている
430億レコードが1日にインポートされている

・Hive Query
1日に2兆レコードを読んでいる
1日3ペタほどのデータを処理している

・Presto Query
1日、1万クエリ以上処理している

 

AWSのコンポーネント

AWSのコンポーネントは下記を使用しています。

EC2
・Hadoop / Presto Clusters
・API Servers

S3
・MessagePack Columnar Storage

RDS
・MySQL for service information
・PostgreSQL for Plazma metadata
・Distributed Job Queue / Schedular

Cloud Watch
・Monitor AWS service metrics

ELB
・Endpoint for APIs
・Endpoint for Heroku

ElastiCache
・Store TD monitoring data
・Event de-duplication for mobile SDKs

 

EMRやSQSは使用していないようです。

 

EMRを使用しない理由として下記があります。

■マシンリソースとストレージを分けた
・データ量が増えているがクエリ量は増えていない
・データ量を増やすためにはノードを増やす必要がある
・リソースは余っている状態になるのでコストがもったいない
・クラウドを使用しているのでリソースを分けた

■HDFSは結構問題があるのでできればHDFSは使用したくない
・HDFSがクラッシュする
・HDFS clusterのアップデートが難しい

そのためS3を使用している

データインポーティングの話

Fluentdにデータをあげるが
レイテンシーやスループットの問題があるので
1レコードずつではなくファイルにしてある程度チャンクにまとめている

FluentdはチャンクにUnique IDを付与するので
Import Queueで重複検証をすることができる

Import QueueはMySQLを使用している
SQSにしない理由はSQSで初め作った時にデータを投げ続けると
重複が発生したのでSQSは使用しないことにした。

ImoprtwokerからPostgreSQLにデータを入れる
・Realtime Storage
→リアルタイム性
→時間をベースに
・Archive Storage
→S3を使用しているので小さいデータを入れるのは効率が良くないのでまとめてアップ

データプロセッシング

列ごとに保存、データ解析の鉄板
独自絡むストレージを作っている

column-based partitioning
time-based partitioning
codeだけ読んで解決できる

S3の問題　Eventual Consistency

1. Writing data / metadata first
> At this time, data is not visible
2. Check S3 data is available or not
> GET, GET, GET…
3. S3 data become visible
> Query includes imported data!

ネットワークコスト

・TDの場合
1000以上のコネクションをS3に貼っている

・recoverable error
→エラーをtdにためて自動でリトライ

・stall checker
進捗をチェックしてkill

リトライ処理

・S3のエラー
500
503
404
→リトライする

syntax error semantic error
exceeded task memory size
→リトライしない

Internal failureはリトライする

リトライ使うことで安定したデータが取れる

 PostgreSQLの落とし穴

ミスマッチが起きる可能性がある
tcpのコネクションは切れるけど裏で動いている
そのためCloudWatchだけみてるとはまる
幾つかの拡張機能が使用されていない

結論

リソースとストレージは分ける
疎結合！
AWSはいくつか落とし穴があるけど避けることができる
たくさんのトレードオフがある
既存のコンポーネントを使用するか、新しいコンポーネントを使用するか
基本にこだわる！

 まとめ

ビッグデータについて初めてのセッションに参加しましたが、AWSを使用しているエンジニアとしてはどのようにAWSを使用してデータを解析、保存、分析しているか詳しく説明されておりとても興味深いセッションでした。

またセッションの中で50万レコードが毎秒インポートされているとお話がありとても驚きました。

 発表資料

[slideshare id=46410399&doc=developers-150329021913-conversion-gate01]